A Semantic Approach to Modularizing SDN Software

Software-defined networking (SDN) refactors the distributed network protocols in the network into an ensemble of centralized programs running at a server (controller) that is separate from the network, creating a rare opportunity to simplify network management with modern software engineering. Yet the SDN software architecture, which often requires coordination among multiple entities over shared states, remains monolithic. The SDN controllers, or network operating systems [4, 8], while exposing to control software a uniform programming interface that abstracts away details of the network hardware, fall short in providing the operating system functionality of coordination among those software. The onus of combining multiple control software that collectively drive the behavior of a single network is falling on the admin to write modular programs. Modular programming, though a natural choice at first glance, often prefixed [3, 11] modularization support in the language features tailored to a particular task. The modular composition itself is tightly coupled with the code that achieves the individual target task, and determining the composition requires clear understanding of the joint intent of every components. Moreover, modular programming solutions, driven by ad hoc requirements lack clear direction and foresight, cannot anticipate future needs, in brief, will not give true modularity to the extremely flexible and ever evolving SDN. To bring modularity to SDN software, in this poster, we advocate a drastically different approach, a shift in SDN software architecture. Rather than embedding modularization in user-supplied modular software, we propose to realize modularization through a distinct architectural primitive implemented at the controller that, decoupled from individual software component, promotes, enforces, and automatically determines modularization. Making modularization an architectural primitive yields solutions to multiple problems. Simplify network management. A truly modular SDN architecture makes the SDN software easier to understand, reuse, and extend. A highly modular control plane is also more configurable and flexible. Independent evolution. Modularization as a distinct primitive frees the component modules from committing to one “right” programming platform that fits all. More importantly, it enables independent evolution of the component software, the conceptual model, and the language abstractions. Incremental deployment. New control software or new modularization principle can be introduced without retrofitting the rest of the system. Of course, modularization as an architectural primitive has been proposed in the past, including layering, software router platforms such as x-Kernel, Click, XORP, and declarative networking [6, 7, 5, 10]; but all these solutions are based on data flow organizational principle that decomposes the software system into parts among which certain data — packets, routes — flow. A data abstraction which, essential to the data flow principle, agreed by every single module in the extremely flexible and evolving SDN, however, is unlikely. To identify a flexible organizational principle, then, is the first key barrier to modularizing SDN software. Can we define a simple yet powerful interface along which meaningful composition can be determined without restricting the flexibility in programming individual software component? A second key barrier is determining the meaningful modularization. Can we automatically discover the right composition without relying on the internalized knowledge of experienced admin who clearly understands the joint intent of every module? Finally, can we put the principle into practical use via a controller service? Can we extend an SDN controller to enable high-level control software for drastically different purposes while at the same time enforcing meaningful composition? We argue that these barriers, while ambitious, are solvable. Moreover, the solutions will shed light on SDN abstractions, guide future design, and improve understanding of dependencies in SDN networks. As a first step towards this goal, this poster will present the design of semantics flow, an organizational principle centered around network semantics — logical properties managed by individual modules. As opposed to data flow principle that breaks the system into parts among which some form of data — packets, routes — flow, semantics flow decomposes the network into semantic units related by logical implication. Leveraging the author’s recent work on database defined network [12], a unique SDN architecture that utilizes a standard SQL database as “the” controller to manage the network with highly customizable control plane abstractions and a open controller runtime, making it a convenient platform to implement the modularization service, we discuss the implementation of semantics flow as a controller service.